IP (Internet Protocol) and related new forms of applications are now incorporating a high degree of personalization. In IP telephony, technologies such as CPL (Call Processing Language) are being defined to allow users to specify their own services and features for controlling the handling of calls. Call processing is currently the domain of experts who thoroughly understand the issue of conflicts among features. Multiple features may interact in ways that create indeterminate behavior. If care is not taken, the addition of a new feature may cause errors in the actions of features that had previously worked flawlessly. New features are evaluated extensively in the design process by experts and tested in conjunction with all other features after the design phase in order to prevent undesired interactions from affecting the end user.
With the advent of personalized features, the reliance on expert designers is no longer possible since users are now able to design their own features. In particular, users who are ordinarily unfamiliar with the issues of formal logic expect features to be understood and conflicts to be resolved in ways that they find natural. It is common for an executive to tell his/her secretary that no calls should be put through in the afternoon and also to tell him/her that if an important customer named Terry March calls to put him straight through. What happens if Terry March calls in the afternoon? It might not be difficult for an ordinary user to identify the conflict if these were the only two instructions specified. However, if these were but two of many policies and were specified at different times, it might be difficult for a user more concerned with other matters to identify the conflict at first glance.
Accordingly, there is a need in the art for a mechanism to allow an ordinary user to test or validate the overall behavior of all policies that he/she has specified so that he/she will understand and approve of all of the interactions among them. Such a mechanism must be sensitive to how a naïve user will tend to specify features and the user's expectation that they will be resolved.
This expectation tends to favor more specific polices over less specific ones. This specificity may address time, people or places. Users could, for example, specify a place such as a particular meeting room and expect it to predominate over a more abstract concept such as policies on all meeting rooms. Specific persons may predominate over more abstract groups, and more specific times may predominate over more abstract time descriptions.
As discussed above, prior art communication services such as the AIN (Advanced Intelligent Networks), have been created by expert engineers who have relied on two options for detecting and resolving conflicts or undesirable interactions:    1. At design time (offline): When different services (often created independently) are integrated into the system, conflicts and their resolution may be undertaken before the features are made available to the end-user. Techniques such as testing and proofs based on formal models can be applied at the requirements, design, and code level to detect interactions, and service precedence or tighter service integration can be used to solve them.    2. At run time (online): When not all conflicts or undesirable interactions can be eliminated at design time; service providers can rely on run-time mechanisms that monitor the system used by the customer and react dynamically to resolve a problem once detected.
In both of the above cases, the resolution is the same for all users, whatever their preferences, intentions, context, or understanding of the services.
As indicated above, new types of communication/collaboration services and applications are emerging, enabled by recent IP telephony protocols and languages such as SIP (Session Initiation Protocol) and CPL (Call Processing Language). These services benefit from the availability of various sources of contextual information (e.g. user's location, presence, schedule, relationships, preferences, etc.) to satisfy a wide variety of requirements. Such services are easily tailored to different vertical markets and are adaptable to changing customer needs and expectations. These services are no longer being defined centrally by expert designers, but rather are being defined at the edge of the network, by-end-users who are not trained in the details of feature design.
In the personalization context addressed herein, end-users have the capability of creating their own services through policies, and are able to define their own solutions to resolving conflicts among these policies. Two main situations can be distinguished:    A. Conflicts among policies of a single user: Such conflicts can be detected at design time, when a user inputs policies in the system. Since the system and the user have knowledge of all the policies of this user, there is an opportunity of resolving conflicts interactively. Moreover, different users have the flexibility to resolve conflicting policies in different ways, which is not the case in traditional prior art systems.    B. Conflicts among policies of multiple users: Since there can be a large number of users, each with their own set of policies, the number of potential conflicts rapidly becomes unmanageable. Design time detection with interactive resolution is inadequate because of the sheer number of conflicts to solve (many of which may never occur if two particular users never call each other) and of the need to negotiate a resolution among multiple users. Conflicts of this type must therefore be detected at run time. U.S. Pat. No. 5,920,618 (Fleischer and Plunkett) entitled Apparatus and Method for Managing Telephony-Based Services describes such a mechanism for Advanced Intelligent Networks (AIN), which uses conflict detection rules described in an expert system. U.S. Pat. No. 6,243,697 (Crowther) entitled Detecting Service Interactions in a Telecommunications Network, also for AIN, makes use of an expert system where interaction rules check services' data parameters for detecting interactions. Conflict resolution can be conventional (resolution mechanisms embedded in the system to provide the same resolution for all users), based on fuzzy logic (e.g. Amer, M., Karmouch, A., Gray, T. and Mankovskii, S. Feature Interaction Resolution Using Fuzzy Policies, in Proceedings of the 6th Feature Interactions in Telecommunications and Software Systems, pp. 94-112, Amsterdam, Netherlands, May 2000. IOS Press), or interactive (e.g. while using the service, the user is prompted when a conflict is detected).
Although several solutions exist for items 1, 2, and B above, there is currently no solution proposed for A where a user creates several individual policies. New languages for telecommunication systems such as IETF's Call Processing Language (CPL) support policies, but CPL assumes an outside mechanism for detecting interactions at design time (it has no mechanism on its own). CPL triggers a feature when all pre-conditions are met and so uses a totally-ordered priority system for resolution.
More particularly, CPL bundles operations for incoming and outgoing calls into two independent decision trees. Since the feature preconditions are ordered, these trees provide an absolute ordering of priorities among the features. This creates the desirable condition of no possibility of indeterminacy among pre-conditions. However this comes at the expense of requiring the user to create this absolute ordering.
The totally-ordered priority system of CPL is sufficient in an execution environment, but is inadequate in a design environment because individual policies no longer exist and hence their management becomes next to impossible. A small change to one individual policy can require a complete restructuring of the CPL script that integrates all of a user's individual policies. However, enabling users to define individual policies may lead to undesirable interactions such as loops and shadowing.
Shadowing may be described as an overlap in feature pre-conditions. One policy may become unreachable and never executed because calls that meet its preconditions are handled by the shadowing policy. So, for example, a policy that forwards all calls that arrive from 2:00 pm to 4:00 pm to voice mail would shadow a policy where all calls from John Doe from 2:30 pm to 3:00 pm should be forwarded directly to the user. In order for the policies to operate properly, an understanding of the common intentions of human users must be developed, as discussed in greater detail below.
Policy conflict detection is present in various domains, principally in the field of network management. Much of the existing work is based on concepts developed by Sloman and Moffett (see Moffett, J. D. and Sloman, M. S. Policy Conflict Analysis in Distributed System, in Journal of Organizational Computing, pp. 1-22, 1994). In particular, Thebaut et al. (Policy management and conflict resolution in computer networks. U.S. Pat. No. 5,889,953, Mar. 30, 1999) have embedded in their system conflict resolution rules that are triggered at run time. Ahlstrom et al. (Recognizing and processing conflicts in network management policies. U.S. Pat. No. 6,327,618, Dec. 4, 2001) provide detection and interactive resolution in their system based on simple policies, but without addressing proper needs of complex communication systems (rich policy language and resolution mechanisms other than plain precedence) and usability concerns (suggestions, hiding the policy language, etc.). Fu et al. tailored Sloman's work to detect and solve IPSec policy conflicts, at run-time, while trying to comply with security requirements (see Fu, Z., Wu, S. F., Huang, H., Loh, K., and Gong, F. IPSec/VPN Security Policy: Correctness, Conflict Detection and Resolution. IEEE Policy 2001 Workshop, January 2001).
Other fields of application also benefit from the use of policy-based systems, such as set forth in Slaikeu (System for the analysis of organizational conflicts, U.S. Patent Application 20010007106, Jul. 5, 2001) who uses policies and detection/resolution (based on an expert system) for organizational conflicts.
In conclusion, none of the foregoing prior art methods are well adapted to solve the particular problem expressed in A), above. Techniques developed for network management are not well-tailored to personalized communication services, features, and applications. Moreover, techniques developed for AIN are not suitable for use in IP systems where services are created at the edge of the network.